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(57) Abstract: A method for activat- 
ing a packet data protocol context in 
a wireless teiecommunication system 
comprising at least one termina] 
and at least one network element 
The network element is arranged 
to deliver packets between the 
wireless telecommunication system 
and other packet data networks. 
Direction-specific service conditions 
are stored in the telecommunication 
system for packets received by the 
network element and designated 
to at least one terminal. The stored 
direction-specific sendee conditions 
determine what kind of service is 
provided for packets received from 
different directions. The direction of a 
received packet is determined and the 
direction-specific service conditions 
relating to the determined direction 
of the packet are checked. The packet 
data protocol context is activated 
according to the direction-specific 
service conditions. 



wo 01/89252 Al liliiillliiiillliiinD 



patent (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM). European For two-letter codes and other abbreviations, refer to the **Guid' 

patent (AT. BE, CH, CY, DE, DK, ES, FI. FR, GB, GR. IE, ance Notes on Codes and Abbreviations'* appearing at the begin- 

IT, LU. MC, ML. PT. SE, TR). OAPI patent (BF, BJ, CF, ning of each regular issue of the PCT Gazette. 
CO, a, CM, GA. GN, GW, ML, MR, NE, SN, TD, TG). 

Published: 

— with international search report 



wo 01/89252 PCT/FIOl/00468 



Network-requested activation of packet data protocol 

CONTEXT 

BACKGROUND OF THE INVENTION 

The invention relates to packet data protocol context activation, and 
5 more particularly to network-requested packet data protocol context activation. 

In the recent years, as services based on the Internet in particular 
have become Increasingly popular, mobile communication systems have been 
provided with networks for packet-switched data. A General Packet Radio 
System (GPRS) has been developed for a Global System for Mobile Commu- 
10 nications (GSM) to provide GSM mobile stations with a packet-switched data 
transmission service. Network elements based on the GPRS system will also 
be applied to a third generation Universal Mobile Telecommunications System 
(UMTS). 

A GPRS network comprises a Gateway GPRS Support Node 

15 (GGSN) and a Serving GPRS Support Node (SGSN). The SGSN is responsi- 
ble for detecting mobile stations capable of GPRS connections in its area, 
transmitting and receiving data packets to and from the mobile stations, and 
for monitoring the location of the mobile stations in Its service area. The gate- 
way support node GGSN serves as a gateway between the GPRS network 

20 and an extemal Packet Data Network (PDN). The gateway support node 
GGSN communicates with the data networks through an interface called Gi. 
Subscriber information is stored in a Home Location Register (HLR). 

In order to be able to access GPRS services, a terminal must first 
make its presence known to the network by carrying out a GPRS attach pro- 

25 cedure. This procedure fomis a logical link between the temiinal and the 
SGSN, making the mobile station accessible for short message transmission 
taking place over the GPRS, for paging taking place tiirough the SGSN and for 
indicating incoming GPRS data. To be more precise, when the temiinal MS 
registers for (attaches to) the GPRS network, i.e. during tiie GPRS attach pro- 

30 cedure, the SGSN creates a Mobility Management (MM) context. User 
authentication Is also earned out by the SGSN in the GPRS attach procedure. 
In order to transmit or receive GPRS data, the temiinal must activate a packet 
data address it wishes to use by requesting the networi< to activate a GPRS 
packet data protocol context, which henceforth will be called a POP (Packet 

35 Data Protocol) context. In connection with the present application, witiiout be- 
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ing restricted to the GPRS system, the term packet data protocol context, or 
PDP context, refers to any logical connection established in order to transmit 
packet switched data between a temninal and a network element responsible 
for the connection, such as a gateway support node. 
5 PDP context activation in the GPRS system makes the terminal 

known in a corresponding GGSN node, enabling cooperation with external 
data networks. To be more precise, the PDP context is created at the terminal, 
in the GGSN and SGSN nodes. The PDP context specifies different data 
transmission parameters, such as the PDP type (e.g. X.25 or IP). PDP ad- 

10 dress (e.g. X.121 address), Quality of Sen/ice (QoS) and Network Sen/ice Ac- 
cess Point Identifier (NSAPI). 

The GPRS standard specifies that a network-requested PDP con- 
text activation can be actuated. This feature enables the PDP context to be 
activated from the network. Such a need may arise e.g. when using a so- 

15 called push service. The idea underlying a push service is that a subscriber 
has in advance agreed with a service provider that he or she will automatically, 
without any separate request, be sent data, e.g. infomiation on stock ex- 
change prices of the day. Also in different telemetric services, the network 
typically transmits data to a mobile station at long intervals, in which case it is 

20 not reasonable to continuously maintain a PDP context, and using a PDP 
context activated from the network could be an altemative. 

The problem with the above-described system is that in principle 
any one connected to the Internet is able to transmit packets to the GPRS 
subscriber. Typically, a GPRS subscriber also pays for received packets, 

25 which means that the GPRS subscriber may have to pay for packets he or she 
never wanted. 

BRIEF DESCRIPTION OF THE INVENTION 

An object of the invention is thus to provide a method and an appa- 
ratus implementing the method so as to enable packet data protocol context 
30 activation requested from a network for received packets to be restricted. The 
objects of the invention are achieved by a method and a networi< part which 
are characterized by what has been disclosed in the independent claims. 
Preferred embodiments of the invention are disclosed in the dependent claims. 

The invention is based on determining service conditions according 
35 to which PDP context activation can be requested from a network. A packet 
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data protocol context is activated (or the activation of a pacl^et data protocol 
context is prevented) according to the service conditions. PDP context activa- 
tion can then only be requested for packets the service conditions allow to be 
delivered to a terminal. According to an aspect of the invention, the service 
5 conditions can be detemiined direction-specifically. When direction-specific 
service conditions are used, the direction of a received pacl<et is detennined 
and the direction-specific service conditions are checked. Hence, a packet 
data protocol context can only be activated for packets received from allowed 
directions, or, con-espondingly, packets received from prohibited directions can 
10 be denied PDP context activation. The direction of a packet may be deter- 
mined e.g. on the basis of the source of the packet, route used by the packet, 
previous node or a combination of the above criteria. The advantage achieved 
is that packets supplied to a terminal from unwanted directions can be pre- 
vented from being delivered, thus enabling extra coste to be avoided. 

According to a second aspect of the invention, the service condi- 
tions can be determined service-type-specifically. A service type is detennined 
according to the features of a packet, typically detemilnlng the application the 
packet is associated with. The advantage achieved Is that It becomes possible 
to treat different type of data associated with different applications in a differ- 
20 ent manner. Consequently, for instance a certain application, e.g. a messaging 
sen/ice, can be allowed to request PDP context activation. 

According to a prefered embodiment of the invention, the service 
conditions are stored subscriber-specifically, which means that different sub- 
scribers may have different service conditions. Service providers thus have 
25 better opportunities to differentiate the service provision for different custom- 
ers. This also enables the subscriber to detemnine the directions the packets 
should be received from and/or the service types the packets should be asso- 
ciated with so that he or she would be willing to pay for them. 

BRIEF DESCRIPTION OF THE DRAWINGS 

30 ^ The Invention Is now described In closer detail In connection with 

the preferred embodiments and with reference to the accompanying drawings, 
in which 

Figure 1 shows a wireless telecommunication system according to 
GPRS technology, 
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Figure 2 shows packets being delivered from a network according 
to a preferred embodiment, 

Figure 3 shows PDP context activation. 

DETAILED DESCRIPTION OF THE INVENTION 

5 The invention can be applied to any wireless network providing 

packet data transmission wherein the network can request packet data proto- 
col context activation. 

By way of example, Figure 2 shows a wireless telecommunication 
system according to GSM/GPRS technology. A wireless mobile station MS 

10 comprises two functional parts: mobile equipment ME itself and a subscriber 
identity module SIM, which is typically located on an integrated circuit card 10. 
Base transceiver stations BTS provide the mobile stations with wireless con- 
nections, and the radio frequencies and channels used by the base trans- 
ceiver stations are controlled by base station controllers BSC. 

15 For circuit-switched services, the base transceiver stations BSC are 

connected to a mobile services switching centre MSC/VLR, which is responsi- 
ble for connection setup for the circuit-switched services and for routing such 
services to correct addresses. Two databases comprising information on mo- 
bile subscribers are utilized: a home location register HLR and a visitor loca- 

20 tion register VLR. Typically, the visitor location register VLR is implemented as 
a part of the mobile services switching centre MSCA/LR. 

The SGSN and the GGSN are responsible for packet-switched 
services. The SGSNs and the GGSNs are interconnected through a backbone 
networi<, which is typically based on an IP protocol. The home location register 

25 HLR in the GSM networic comprises GPRS subscriber infonnation and routing 
information. External packet data networks PDN may include e.g. a GPRS 
networic of another network operator, the Intemet, an X.25 networi< or a private 
local area network. A border gateway BG provides access to a GPRS back- 
bone network between operators. As far as the extemal data networks PDN 

30 are concerned, the GGSN is a router to a subnetwori< since the GGSN hides 
the GPRS functionality. In the example of Figure 1 , a server SI can be directly 
connected to the GPRS network and servers S2 and S3 can be connected to 
the GPRS network through an extemal data network PDN, such as the com- 
mon Internet. Figure 1 also shows a firewall FW functionally connected to the 

35 GGSN to enable unauthorized access to the GPRS network to be prevented. 



wo 01/89252 



PCT/FIOl/00468 



For a more detailed description of the GSIVI/GPRS networi^s, refer- 
ence is made to tlie GPRS specifications issued by ETSI (European Tele- 
communications Standards institute), and to The GSM System for Mobile 
Communications by M. Mouly and IVI. Pautet, Palaiseau, France, 1992, ISBN: 
5 2-9507190-0-0-7. 

According to a preferred embodiment, network-requested PDP 
context activation is determined in the GPRS networl< on the basis of the di- 
rections of received pacl<ets and/or service requests contained in such paclc- 
ets. The GGSN may comprise a functionality to be described in the following 
10 for checking the infonnation on the packets and for activating a PDP context 
only for packets meeting predetennined conditions. 

Preferably, the service conditions detemriining what kind of service 
will be provided for received packets are stored 200 in the GGSN. The service 
conditions may be direction-specific, which means that they detennine a serv- 
15 ice that can be provided for a packet received from a certain direction. The 
service conditions can also be stored in another networic element, such as in 
the subscriber database HLR. 

When the GGSN receives 201 a packet designated to the mobile 
station MS from an extemal networic, the GGSN can detemnlne 202 the direc- 
20 tion from which the packet to be delivered to the mobile station MS was re- 
ceived. From the stored service conditions, the GGSN checks 203 the delivery 
conditions relating to the direction of the packet. It can be checked 204 from 
the service conditions whether the packet received from the detemnined direc- 
tion (virtual and/or physical) Is allowed to be delivered to the mobile station 
25 MS. If not, the packet is ignored 205. If the service conditions allow the packet 
to be delivered from the detennined direction, the GGSN can request 206 PDP 
context activation for one or more mobile stations MS. If possible, the PDP 
context is activated and the packet can be delivered to the MS, utilizing the 
activated PDP context. It should be noted that the GPRS networi^ typically also 
30 user-specifically checks in step 206 whether it Is possible to activate the PDP 
context. The PDP context cannot thus necessarily always be activated even if 
allowed by the sen/ice conditions. 

The great advantage achieved is that the GPRS network enables 
conditions to be detenmined for PDP context activation from the networi< and, if 
35 necessary, PDP context activation to be denied to packets received fi'om non- 
reliable directions. 
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Network-requested PDP context activation can be determined ac- 
cording to direction-specific service conditions on the basis of the physical 
and/or logical direction of the packets. A physical direction is detennined on 
the basis of the physical data transmission device, e.g. on the basis of a fixed 
5 line. Packets received from the same physical direction (e.g. from a cable of a 
router) may have different logical directions. If the packets are encrypted such 
that the GGSN is able to find out the sender that carried out the encryption, 
the packets received from the same physical direction can be treated in differ- 
ent ways on the basis of the sender. The logical direction of the packets can 
10 be determined e.g. on the basis of the tentiination point that carried out tun- 
nelling, which means that the network elements therebetween are incapable of 
detunnelling. 

According to a preferred embodiment, the stored direction-specific 
service conditions comprise information on allowed nodes. The support node 

15 then, in step 202, determines the node from which a received packet was 
transmitted. The support node activates (206) the packet data protocol context 
for the mobile station MS if the stored service conditions allow packets to be 
transmitted from the determined node to the mobile station. The advantage is 
that requesting PDP context activation can only be allowed for packets re- 

20 ceived from reliable network elements. A GPRS network operator can then 
e.g. only allow packets received from a server (SI) in its own network or pack- 
ets received through a border gateway from another GPRS networi< to be de- 
livered. 

An alternative is to detemnine an address space in the direction- 
25 specific service conditions, wherein PDP context activation is allowed for 
packets delivered from addresses belonging to the address space. The GGSN 
then detennines the source address to the received packet unit and whether 
the source address of the received packet unit belongs to the stored address 
space. The GGSN activates the PDP context if the received packet belongs to 
30 the address space. The direction-specific service conditions may also require 
that only packets tunnelled and encrypted at certain source addresses can be 
delivered to the MS. For instance, different tunnelling techniques of VPN 
(Virtual Private Network) tunnelling can be used. 

It is also feasible to determine service-specific service conditions. 
35 Particulariy, service types can be determined such that packets according to 
the particular service types are allowed to be delivered, i.e. the GGSN can re- 
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quest PDP context activation for such packets. The service-type-specific serv- 
ice conditions are then preferably stored 200 in the GGSN. Typically, a service 
type is the application type associated with a packet, i.e. the service type de- 
ternilnes the application with which the packet is associated. The service-type- 
5 specific service conditions determine what kind of service will be provided for 
the received packets associated with different service types and designated to 
the mobile station MS. The service type associated with the packet designated 
to the mobile station is determined 202 from the packet received 201 by the 
GGSN. The delivery conditions associated with the sen/ice type of the packet 

10 are checked 203 from the stored service conditions. If the service conditions 
allow the packet to be delivered, the packet data protocol context can be acti- 
vated 206 according to the service-type-specific service conditions. 

The service types can preferably be determined according to appli- 
cations determinable from the packet The GGSN can then detennine the port 

15 number contained in the packet and request PDP context activation on the 
basis of the service conditions according to the determined port number. Con- 
sequently, only packets comprising a desired port number can thus be allowed 
to be delivered. The sen/ice conditions may e.g. detennine that PDP context 
activation can be requested for packets associated with an application ac- 

20 cording to an HTTP (Hypertext Transfer Protocol) protocol. The sen^ice condi- 
tions can then detennine that PDP context activation is allowed for packets 
comprising port number 80 (number 80 is typically used for identifying an 
HTTP application). The GGSN detemnines the port numbers of the packets, 
being then allowed to request PDP context activation for packets according to 

25 port number 80. 

According to a preferred embodiment, the service conditions are 
stored subscriber-speclfically, i.e. the service conditions can preferably be 
stored for different subscribers on the basis of an IMSI identifier. Hence, the 
allowed directions and/or service types can be determined in a particularly in- 

30 dividual manner, enabling the subscriber to affect the service conditions. Fur- 
thermore, subscriber-group-specific service conditions can be determined. In 
such a case, in addition to finding out the direction and/or service type of a 
packet, the GGSN also finds out the IMSI Identifier of the receiver of the pack- 
ets on the basis of the subscriber information in the network. From the sub- 

35 scriber-specific service conditions, the GGSN checks what kind of sen/ice can 
be provided for the received packets. Particulariy, it is found out whether the 
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service conditions allow the packet to be delivered. The subscriber can then 
decide on the directions the packets should be received from and/or the serv- 
ice types the packets should be associated with so that he or she would be 
willing to pay for them. It is also feasible that the subscriber-specific service 
5 conditions deny PDP context activation to a certain subscriber for packets re- 
ceived from the network, entirely regardless of the direction they are received 
from or the service type they are associated with. 

According to a prefenred embodiment, in addition to the conditions 
relating to allowing packets to be delivered, the direction- and/or service-type- 

10 specific service conditions can also detemiine other conditions. The sen/ice 
conditions may detemiine e.g. the PDP type allowed, infomiation on the QoS 
(Quality of Service) allowed or other such infonmation concerning the PDP 
context. The information can also be infomiation relating to other aspects of 
service provision, such as charging information. This infomiation can be tied to 

15 the direction and/or service type of a packet, i.e. a different PDP context can 
be activated for packets received from different directions and/or packets of 
different service types, according to the stored service conditions. This en- 
ables a convenient way of determining different service provision for packets 
received from different directions and/or having different service types. For 

20 instance, the subscriber could be charged differently for packets received from 
different directions. If the information is information relating to charging. In- 
structions for carrying out the charging must be delivered to a GPRS charging 
centre, which charges for the delivered packets/PDP context accordingly. If 
the service condition is a service condition relating to a PDP context type 

25 and/or quality of service, the GGSN can request PDP context activation for an 
accepted packet by applying type and/or quality parameters according to the 
service condition. 

The functionality described above in connection with Figure 2 can 
also readily be implemented at another network element than the GGSN. For 

30 example, the firewall FW functionally connected to the GGSN can be arranged 
to implement the above-described checking procedures (200 to 204) regarding 
the direction and/or service type of packets and to deliver a packet to the 
GGSN if the service conditions allow the packet to be delivered. Next, the 
GGSN may cany out network-requested PDP context activation according to 

35 the prior art known per se. 
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The invention can preferably be implemented by software means in 
a processor of a network element in a wireless telecommunication system. 
Preferably, the network element is the gateway support node GGSN or the 
firewall FW functionally connected to the GGSN. The network element pref- 
5 erably comprises one or more processors, a bus for communicating with other 
devices and a memory to store sen/ice conditions by means of the processor 
and the bus. If the invention is implemented by software, the processor exe- 
cutes the software stored in the memory which canies out the steps illustrated 
in Figure 2 each time the network element receives packets from the external 

10 networks PDN. It is also feasible that the service conditions are stored in an- 
other network element, such as the subscriber register HLR, in which case the 
networi< element comprising the inventive functionality retrieves the service 
conditions from the other network element- 
Figure 3 illustrates networi<-requested PDF context activation. It is 

15 assumed that packets designated to the MS are received from outside the 
GPRS network and that the mobile station MS is known in the GPRS network, 
i.e. the MS has perfonned a GPRS attach procedure. A PDP context is cre- 
ated and the packets are tunnelled using a GTP (GPRS Tunnelling Protocol) 
protocol. The GGSN may request PDP context activation if the service condi- 

20 tions allow a received packet to be delivered to the mobile station MS (step 
206 in Figure 2). The GGSN may request routing infonnation from the network 
element comprising the home location register HLR (Send Routeing Info for 
GPRS). If the network element comprising the HLR decides that the sen/ice 
request can be implemented for the mobile station MS, it replies to the request 

25 issued by the GGSN (Send Routeing Info for GPRS Ack). If the address of the 
correct serving node SGSN can be found in the reply received from the HLR 
and the mobile station MS can be accessed, the GGSN infonns the SGSN of 
the received data (PDU Notification Request). Such a message comprises an 
IMSI identifier to identify the subscriber, information on the PDP type and PDP 

30 address. The SGSN transmits an acknowledgement to the GGSN If it is going 
to ask the mobile station MS to activate the PDP context (PDU Notification 
Response). The SGSN transmits a PDP context activation request to the mo- 
bile station MS (Request PDP Context Activation). 

In response to the request, the MS delivers the PDP context acti- 

35 vation request to the SGSN (Activate PDP Context Request). At this stage, 
security procedures, such as authentication, between the mobile station MS 
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and the SGSN can be canied out. If the mobile station MS has the right to ac- 
tivate the PDP address, the SGSN can create the PDP context for the mobile 
station MS. In order to map the PDP context into the GPRS network mobility 
management, the SGSN creates a TID (Tunnel Identifier, which is used in the 
5 GPRS tunnelling protocol between the network elements in order to identify 
the PDP context) for the requested PDP context on the basis of the IMSI iden- 
tifier and the NSAPI (Network layer Service Access Point Identifier) received 
from the mobile station MS. The PDP context activation request is delivered to 
the GGSN (Create PDP Context Request).; The SGSN stores the IP address 

10 of the GGSN (which can be modified from the logical name) in connection with 
the requested PDP context (GGSN Address in Use) and uses the address as 
long as the PDP context exists. 

If the GGSN can accept the PDP context activation request, the 
PDP context activation can be completed. The GGSN adds a new context to a 

15 PDP context table and produces a charging identifier. The GGSN may also 
deliver a message to the SGSN to indicate the PDP context activation (Create 
PDP Context Response). In response to this, the SGSN adds an NSAPI iden- 
tifier to the address of the GGSN. The SGSN further infomis the mobile station 
MS of the PDP context activation (Activate PDP Context Accept). Subse- 

20 quentiy, packets from reliable directions and/or packets provided with ac- 
cepted service requests can be delivered to the mobile station MS according 
to the service conditions. 

The invention can also readily be applied to wireless telecommuni- 
cation systems other than the GSM systems. The so-called third generation 

25 wireless telecommunication systems, such as the UMTS (Universal Mobile 
Telecommunications System) or IMT-2000, for example, can support PDP 
context activation requested by the network, which enables procedures illus- 
trated in Figure 2 to be utilized. The packet-switched data transmission in the 
UMTS system will be mainly similar to the GPRS system in the GSM, so the 

30 invention is also readily applicable to the UMTS system. Furtiiemipre, other 
wireless telecommunication systems to which the invention can be applied 
include e.g. wireless local area networks WLAN. 

It is obvious to one skilled in the art that as technology advances, 
the basic idea of the invention can be implemented in many different ways. 

35 The invention and its embodiments are thus not restricted to the above- 
described examples but they may vary within the scope of the claims. 
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CLAIMS 

1. A method for activating a packet data protocol context in a wire- 
less telecommunication system comprising at least one terminal and at least 
one network element, the network element being an^anged to deliver packets 

5 between the wireless telecommunication system and other packet data net- 
works, characterized by 

storing direction-specific sen/ice conditions in the telecommunica- 
tion system for packets received by the network element and designated to at 
least one terminal, the direction-specific service conditions determining what 
10 kind of service is provided for packets received from different directions, 

determining the direction of a received packet to be delivered to the 

terminal, 

checking the direction-specific service conditions relating to said 
determined direction of the packet, and 
'1 5 activating the packet data protocol context according to the direc- 

tion-specific service conditions. 

2. A method as claimed in claim 1, characterized by 

the stored direction-specific service conditions comprising informa- 
tion on allowed nodes, 

20 determining the node from which the received packet was trans- 

mitted, and 

activating the packet data protocol context in response to the fact 
that the stored sen/ice conditions allow packets to be transmitted from the de- 
termined node to the terminal. 
25 3. A method as claimed in claim 1 or 2, c h a ra c t e riz e d by 

determining an address space in the direction-specific service con- 
ditions, packet data protocol context activation being allowed for packets de- 
livered from the address space, 

determining the source address of the received packet, 
30 checking whether the source address of the received packet be- 

longs to said address space, and 

activating the packet data protocol context in response to the fact 
that the received packet belongs to said address space. 

4. A method as claimed in any one of the preceding claims, 
35 characterized by 
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storing, in addition to the direction-specific service conditions, 
servlce-type-specific sen/ice conditions in the network element, the service- 
type-specific service conditions determining what kind of service is provided 
for received packets of different service types, 
5 determining the service type associated with the received packet 

designated to the terminal, 

checking the service conditions relating to said service type and 
said direction from the stored service conditions, and 

activating the packet data protocol context according to the service- 
1 0 type-specific and direction-specific service conditions. 

5. A method for activating a packet data protocol context in a wire- 
less telecommunication system comprising at least one terminal and at least 
one network element, the network element being arranged to deliver packets 
between the wireless telecommunication system and other packet data net- 

15 works, characterized by 

storing service-type-specific service conditions in the telecommuni- 
cation system for packets received by a support node and designated to at 
least one terminal, the service conditions determining what kind of service is 
provided for received packets of different service types, 
20 determining the service type associated with a packet received by 

the network element and designated to the terminal, 

checking the service conditions relating to said determined service 
type of the packet, and 

activating the packet data protocol context according to the service- 
25 type-specific service conditions. 

6. A method as claimed in claim 5, characterized by 
storing the service-type-specific service conditions on the basis of 

port numbers, 

detemiining the port number contained in the packet received by 
30 the networi< element and designated to the tenminal, and 

activating the packet data protocol context according to service 
conditions relating to said determined port number. 

7. A method as claimed in any one of the preceding claims, 
characterized by 

35 storing the service conditions subscriber-specifically. 
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8. A method as claimed in any one of the preceding claims, 
characterized by 

the service condrtions comprising Infomiation on the quality of 
service and/or charging for the packets of the packet data protocol context, 
5 and 

activating the packet data protocol context according to the quality 
of service detennined in the sen/ice conditions and/or the charging of the 
packet data protocol context according to the charging information in response 
to the fact that the service conditions allow packets to be delivered. 

"^0 9. A network part in a wireless telecommunication system, which 

network part is an^anged to deliver packets between a wireless telecommuni- 
cation network and a fixed packet data network, characterized in that 

said network part comprises means for storing direction-specific 
service conditions for packets received by the network element and desig- 

15 nated to at least one terminal, the direction-specific sen^ice conditions deter- 
mining what kind of service Is provided for packets received from different di- 
rections, 

said network part is arranged to determine the direction of a re- 
ceived packet to be delivered to the terminal, 
20 said networi< part is anranged to check the stored service conditions 

relating to said detemiined direction of the packet, and 

said network part is an-anged to request packet data protocol con- 
text activation according to the direction-specific service conditions. 

10. A network part as claimed in claim 9, characterized in 

25 that 

said network part is arranged to determine the node that transmitted 
the received packet and/or the source address of the received packet. 

11. A network part in a wireless telecommunication system, which 
network part is an-anged to deliver packets between a wireless telecommuni- 

30 cation network and a fixed packet data network, characterized in that 
said network part comprises means for storing service-type-specific 
service conditions for packets received by the network element and desig- 
nated to at least one tenninal, the service-type-specific service conditions de- 
termining what kind of service is provided for received packets of different 

35 service types, 
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said network part is arranged to determine the service type of a re- 
ceived packet to be delivered to the terminal, 

said network part is an-anged to check service conditions relating to 
said determined service type of the packet, and 
5 said network part is anranged to request packet data protocol con- 

text activation according to the service-type-specific service conditions. 

12. A network part as claimed in claim 11, characterized in 

that 

said network part is arranged to. detenmine the port number of the 
1 0 received packet. 

13. A network part as claimed in any one of claims 9to 12, char- 
acterized in that 

said network part comprises software means for detemiining the di- 
rection and/or service type of the packet and for checking the service condi- 
15 tions. 

14. A network part as claimed in any one of claims 9 to 13, char- 
acterized in that 

said network part is a gateway GPRS support node GGSN in a 
GPRS system and/or a firewall functionally connected to the gateway support 
20 node. 
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